Mobility Drive is an application for taxi drivers, allows them to get rides and manage their day hours while they are in the taxi car. The driver is connected to dispatch system and part of taxi station. The dispatcher in the station add rides to the system and they sent to the relevant driver (depends on distance and some constrains that I will take about them later, like number of passengers, ability to take people with disabilities, or number of baby seats).

As part of my work at Here Mobility I took part by designing the main app flows and use cases such as:

1. Login flow 

2. Change driver status

3. Get a new ride

4. Ride flow (while driving to and with the client)

5. Settings and about pages

6. Upcoming rides and rides history

7. Alerts and messages in the app

I joined to the branch of Here Mobility from the beginning of its establishment. It means that I planned and designed this application from scratch while we had the general idea of the product. 

Another challenge is to combine the right flow for two different platforms, web and native application. These are two different products, for different users but should communicate with each other.

The last challenge (but not least) refers to the targeted users who will use it while driving. In each pixel in the application I took into consideration to do each action while driving, while the user is not in his full attention for the app. All the flows and screens should be clear and usable while doing another action in the background.

This flow is the complicated login flow I have ever worked on. The reason for that is because the user had to be registered first in the taxi station dispatch system before he will be able to login. After adding a driver, the driver gets an SMS with a link to download the app. All the application users should be registered with their phone number to be able to get the rides of the relevant station they are connected to. 

In this case, while the phone umber is the unique ID for user, the driver is able to connect to the application by the same ID, his phone number. For security matters, the user should enter 4 digits code he received in SMS to login the app, after enter his phone number.

Login with two steps only.

The driver has the ability to manage his shift, it means to decide when to be 'online' and when he wants to get rides from the dispatch system. 

There are 4 statuses the driver can move between them:

1. Free - means the driver in his car waiting for rides to arrive, he is available to get rides and searching for them in his area.

2. On a ride - means that the driver is on shift but he is busy, he can get pre-booked future rides but not immediate rides. 

3. On a break - means that the driver is on shift but he cannot get rides right now ( like because of car mechanical problem).

4. Of duty - Means the driver is not on shift and will not get rides from the dispatch system.

The behaviour for this four statuses is reachable and user can do it by one click from the main app screen. By clicking on the car icon, user can choose which status to change, the changed sent to the taxi station dispatcher and the connection between them is immediate and in real time.

While user changes the status to "On a Ride" it means that he took a ride with street hailer and he is busy. While clicking on this status the Street Hail page will be opened and the driver should insert destination. The pickup point will be always the current location but user can change it if he wants. All the rest data in the page is not mandatory. While clicking on "Ride" button the driver will see a navigation to the destination (same as described in forth flow.

While driver is on his way on the road, he needs to be updated when new ride arrives to his device. The rides will appear on his screen for several seconds and if he will ignore it, it will disappear and will be presented to another driver, until one of them will approve it.

This screen includes a lot of data and came up with this flow was very challenging. While user on the main screen (which appears above), he will see a new ride request in a prominent way. The new ride request designed to be all over the screen (arrives from bottom) and user can: 

1. Accept the ride and start the navigation. User can click anywhere on the screen to accept it, this behaviour made to make the acceptance of the ride much easiest instead of clicking on a specific button on the screen. While driving it is make more sense to click all over the screen (except the 'Reject' button area) to take the ride.

2. Reject the ride by clicking on 'Reject' button to back to the main screen and send this ride to another available driver

3. Ignore it and it will disappear from his screen (there is a timer moves from left to right, full to empty)

You can see in the second screen above that this kind of ride is pre-booked. In this case the driver should arrive on time to the client (which asked several hours or days ago this ride). The price in this case is fixed, which means that the dispatcher in the taxi station closed a price with the client for this ride, and this is what the driver should demand in the end of the ride.

In the new ride request the driver should be notify, in addition to the pickup point and destination addresses, the constrains of the ride. In the example above, the driver is notify that this ride is for 1 person, which has 2 suitcases and a baby (need to take out the child seat) and this person may has a physical disability.

While driver accept a ride, he will see an instructions how to reach the passenger pickup point. He will see a map, his location, a header with manoeuvres instructions. Also, the driver is always see how much time it will take to arrive to the pickup point (e.g. "4 min"), what is the arrival estimation time (e.g. "09:45") and what is the distance (e.g. "1.7 km"). All this data update in real time and the driver can see it always on the bottom part of the app.

While driver is near the pickup, the drawer will move up a bit and he will see the button of reaching to passenger. When driver arrives to that point, he can to click on this button. If driver will not click on this, and will start to drive, the application will direct him to the destination point. At all time the driver can reach the button of calling the passenger.

Driver can open the drawer to see more functionalities which may relevant during the ride, like calling dispatcher, remove or add navigation sounds or cancel the ride. 

On the second line of the screens above, you can see the screens while the driver wait for passenger, while driver navigate to destination and while see the summary ride screen.

The driver can enter to the menu and change some settings like the language of the app and sounds. User can logout from the app and while doing that he will direct to the login page (see above) and will not get rides.

In the about page the user can read some legal data about terms and condition, or contact the support team.

Through the menu user can also see the pre-booked upcoming rides and the ride history (all the rides he finished or approved and then canceled).

In the upcoming ride section user can see in a prominent way the rides that scheduled for today, they will appear in Green. Driver can click on each to see more details about the ride. Driver also can activate the ride and can reject the ride. By rejecting a ride, a message sent to the dispatcher to attached this ride to another driver.

The driver can also see the next days planned rides and can see rides that scheduled but canceled by the dispatcher, they will appear in Red.

The third kind of indication is the Orange one, which urge the driver to start the ride since he needs to start navigate to the pickup point.

When a driver wants to see his previous ride he can enter to the "Past Rides" section and see all the days that he worked. By clicking on each day, the driver can see a detailed information about the ride he had, the time of them, the pickup and destination addresses, the type of the ride (street hailing, manually allocated...) and more.

In the application I created a unique experience for the communication of the app with the driver. 

I made an illustrated scenarios based on the message content. You can see below some of the icons I made and how they are added to the messages in the app.